The present invention relates to replacing passwords with user public/private key certificates.
Currently, many websites and applications require a user login and password for access. Each new web-site requires a different user-name and password. Password managers have been introduced that consolidate them under just one password, and two factor authentication is sometimes used to improve security, but none of these approaches actually eliminates passwords or improves the user experience. Meanwhile, passwords are now the most common security breach in computer systems. Phishing expeditions continually deceive naive users into revealing their passwords, or criminals successfully guess those most commonly used. The password concept is broken—password convenience is overridden by the losses incurred.
TLS (Transport Layer Security) and its predecessor, SSL (Secure Sockets Layer) are Internet standards for two things: 1) services (servers) authenticating themselves to users (clients), and 2) encrypting messages that are decipherable by only the two parties in the connection. SSL was created by Netscape in 1995 and renamed to TLS when made into a standard.
Server Certificates. TLS uses X.509 certificates, each of which have a digital signatory. The signatory itself must also have a certificate, which has a second signatory. And that second signatory possesses a certificate with a third signatory, and so forth, leading to a chain of certificates. Starting with a root signatory, each certificate signs the next until reaching the server's (end entity) certificate, which is the last (“leaf”) certificate (the certificate used to access a website server). A leaf certificate cannot be used to sign other certificates. According to the TLS protocol, this chain starts with a self-signed certificate, which is from a single, universally-trusted root.
For simplicity and authentication convenience of services, this trusted root certificate has been included in a select group of root Certificate Authority (CA) certificates. Any CA in this select group can sign other certificates. The select group can vary in size, but membership is determined by a consortium of browser vendors, Operating Systems vendors, and Certificate Authorities called the CAB Forum.
Trust in a leaf server certificate is established the client validating the signature of each certificate in the server's chain in reverse order, starting with the leaf. Encountering any trusted and validated certificate from this select group establishes trust in the leaf certificate. A second test challenges the server to prove it possesses the correct private key for the leaf certificate. Success in both of these tests is necessary for an authenticated, trusted connection.
Mutual Authentication. TLS was symmetrically designed to allow both services and users to be authenticated using certificates, called mutual TLS. Client-certificates, like server-certificates, were expected to use an external, trusted, third-party signatory in their chain-of-trust that is trusted to undertake the burden of establishing the user's actual identity. It was recognized already in 1995 that there were problems with this approach. First, few CAs would take the job of certifying the identity of individuals needing certificates. Second, any given service might not trust any given CA to certify its users. Third, user-certificate CAs were an enormous additional bureaucracy. Hence, user-certificates were deemed to be not viable for normal users of the Internet, and from the outset, the common user-name/password was instead adopted for user-authentication.
Currently, a Public Key Infrastructure (PKI) exists to allow users to verify the identity of a website, to make sure they are communicating with the correct entity. Public/Private key encryption is used for site authentication. A trusted, third-party Certificate Authority (CA) can be used to authenticate the identity of a website. In this process, the owner of a domain generates a public/private key pair. The public key of the website is wrapped in a Certificate Signing Request (CSR) along with other information, and it is signed with the private key. This CSR is submitted to the CA for the creation of a Certificate. The trusted CA validates the ownership of the website's web address using whatever means determined by that CA to be necessary and sufficient. The CA then uses the private key of an intermediate certificate, which was itself signed by a root certificate, to sign a Certificate for the website. The signed website certificate is referred to as a leaf certificate, which identifies the website but cannot be used to sign other certificates. The website leaf Certificate thus links to the trusted CA's own trusted certificate, referred to as a root certificate, by way of the intermediate certificate that signed it, forming a chain of certificates. By trusting the CA's root certificate, any client connecting to the website can trust the leaf certificate presented by the site as a valid identity of the website. Let's Encrypt® is the most common root certificate CA today.
Consumer Device makers have incorporated hardware security modules (HSMs) to store encryption keys, biometric data (for fingerprint and face recognition authentication). WebAuthn is a proposed standard by the W3C with input from the FIDO alliance, of which Google is a part, that uses asymmetric, public/private encryption as a mechanism for second authentication factor. The private key can be stored internally in a consumer device's HSM or in a special, separate key-storage device. The proposed standard has multiple private keys, one per site, and requires new keys in the event of a lost device.
People have difficulties remembering passwords, so they often use the same password everywhere. Moreover, passwords are cryptographically weak credentials, as they can be guessed and are shared secrets. In the past ten years, mobile devices have caused a proliferation of Internet accounts, which has stimulated demand for credential alternatives.
As detailed above, TLS has been limited by the need for third party CAs. Many companies offer alternative client credentialing systems that do not use TLS, including two-factor authentication, password managers, and many other systems to augment the standard password. A few use TLS for client-authentication, but paired with PKIs (Public Key Infrastructures) that operate a Certificate Authority (CA) to issue certificates to specific individuals for use with the service. There are a number of described uses of self-signed certificates to authenticate a particular device, such as Published Application US 20130145151 (device authentication), Published Application US 20120036364 (network device, such as a camera), and Published Application US 20190075099 (for virtual servers, with a broker).
Starting with the FIDO Alliance almost ten years ago up to today's WebAuthn consortium of companies (notably, Google) and many other companies have devised alternatives to avoid the perceived deficiencies of TLS for client-authentication but still use TLS for server authentication and encrypted communications.
It would be desirable to have a password replacement that is easy to use, can be used across multiple devices, and allows recovery in the event of a lost device.